Open shortest path first routing for hybrid networks

ABSTRACT

In some examples, a method includes determining, with a Software-Defined Networking (SDN) controller, a network topology for an SDN portion of a heterogeneous network. SDN portion  111  can, for example, be formed by hybrid and SDN devices. The heterogeneous network can, for example, include a non-SDN portion that borders SDN portion  111  and is formed by non-SDN devices. The method can further include sending tunneling instructions to a first hybrid border switch to create a tunnel between the first hybrid border switch and a second hybrid border switch in order to allow Open Shortest Path First (OSPF) routing between two non-SDN portions separated by an SDN portion within the heterogeneous network.

BACKGROUND

Computer networks can be used to allow networked devices, such aspersonal computers, servers, and data storage devices to exchange data.Computer networks often include intermediary datapath devices such asnetwork switches, gateways, and routers, to flow traffic along selecteddatapaths for routing data between networked devices. Such datapathscan, for example, be selected by a network controller, administrator, oranother entity, and can, for example, be based on network conditions,network equipment capabilities, or other factors.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram of a network, according to an example.

FIG. 2 is a flowchart for a method, according to an example.

FIG. 3 is a flowchart for a method, according to another example.

FIG. 4 is a flowchart for a method, according to another example.

FIG. 5 is a flowchart for a method, according to another example.

FIG. 6 is a diagram of an SDN controller, according to an example.

FIG. 7 is a diagram of machine-readable storage medium, according to anexample.

DETAILED DESCRIPTION

The following discussion is directed to various examples of thedisclosure. Although one or more of these examples may be preferred, theexamples disclosed herein should not be interpreted, or otherwise used,as limiting the scope of the disclosure, including the claims. Inaddition, the following description has broad application, and thediscussion of any example is meant only to be descriptive of thatexample, and not intended to intimate that the scope of the disclosure,including the claims, is limited to that example. Throughout the presentdisclosure, the terms “a” and “an” are intended to denote at least oneof a particular element. In addition, as used herein, the term“includes” means includes but not limited to, the term “including” meansincluding but not limited to. The term “based on” means based at leastin part on.

Software-defined networks/networking (SDN) can allow for the decouplingof traffic routing control decisions from the network's physicalinfrastructure. For example, in an SDN, such traffic routing controldecisions (e.g., which port of a network switch should be used toforward traffic en route to a given destination) can be determined by anentity (e.g., a network controller) that is different from the routingdevice itself (e.g., the network switch tasked with forwarding thetraffic). A network controller used to implement an SDN (i.e., an SDNcontroller) can, for example, be programmed to: (1) receive dynamicparameters of the network from intermediary datapath devices (e.g.,network switches), (2) decide how to route packets over the network, and(3) inform the devices about these decisions.

The OSPF (Open Shortest Path First) protocol is a common InternalGateway Protocol (IGP) that can provide robust and efficient routingsupport in demanding Internet environments. Certain link-state routingprotocols, such as OSPF, can face difficulties when traversing between a“legacy” or non-SDN portion of the heterogeneous network (e.g., an areaof the network that includes only legacy switches or other non-SDNcapable devices) into an SDN portion of the network. For example, OSPFis well-suited to run on large routing domains, and the transitionbetween non-SDN and SDN networks may break up the routing domain and cancause network connectivity issues.

Certain implementations of the present disclosure can be used to extendan OSPF routing domain across multiple SDN network portions in aheterogeneous network. One implementation of the present disclosure isdirected to an SDN controller programmed to determine a network topologyfor an SDN portion of a heterogeneous network and to send tunnelinginstructions to a first hybrid border switch to create a tunnel betweenthe first hybrid border switch and a second hybrid border switch inorder to allow Open Shortest Path First (OSPF) routing between twonon-SDN portions separated by an SDN portion within the heterogeneousnetwork.

Certain implementations of the present disclosure can be used to improvevarious network applications, such as: (1) extending routing domainsbeyond SDN network portions in heterogeneous networks, (2) providingbetter manageability and flexibility because routing networks can bedesigned easily without concerns about the network types involved (i.e.,SDN or legacy), (3) implementations can be extended across differentnetworks and the entire network can be visualized (or virtualized) as asingle network, and (4) virtual routing domains can be designedinvolving SDN and non-SDN network types. Other advantages ofimplementations presented herein will be apparent upon review of thedescription and figures.

FIG. 1 is a diagram of an example heterogeneous network 100 including anexample Software-Defined Networking (SDN) controller 102 includingvarious combined hardware and software modules 104 and 106 as well asvarious SDN switches 108, 110, 112, and 114, various hybrid (SDN- andlegacy-capable) switches 116, 118, and 120, and various legacy-onlyswitches 122, 124, and 126. The term “heterogeneous network” as usedherein can, for example, refer to a network where both traditionalnetworking as well as SDN protocols operate in the same environment.Such a heterogeneous network can, for example, include one or moretraditional portions, which rely on legacy devices, and one or more SDNportions 111, which rely on hybrid and/or SDN devices. In such a networka network manager can, for example, configure the SDN control plane todiscover and control certain traffic flows while traditional,distributed networking protocols to direct the rest of the traffic onthe network.

In some implementations, heterogeneous network 100 includes varioushardware switches or other routing devices that are connected usingphysical cabling or other physical data channels. In someimplementations, heterogeneous network 100 is a virtualizedheterogeneous network. Such a virtualized heterogeneous network can, forexample, overlay physical hardware of a network including multiplecomputing devices or just a single computing device. The structure andfunctionality of the various modules of SDN controller 102 are describedin detail herein. FIG. 1 further illustrates various source anddestination nodes 128, 130, and 132. For purposes of consistency, node128 will be referred to herein as a source node, and nodes 130 and 132will be referred to as destination nodes. It is appreciated that in someimplementations, node 128 can serve as a destination node and nodes 130and/or 132 can serve as source nodes. It is further appreciated thatcertain nodes may serve as a source node for a period of time (e.g.,while sending data) and then switch into a receiving node for a periodof time (e.g., while receiving data). The use of the terms “source” and“destination” are merely intended to refer to a flow of traffic at agiven time.

As provided above, network nodes within heterogeneous network 100 canforward traffic along the datapath based on metadata within the traffic.For example, traffic in the form of a packet can be received at networkswitch 116 (or another suitable intermediary network node). Forconsistency, the industry term “packet” is used throughout thisdescription, however, it is appreciated that the term “packet” as usedherein can refer to any suitable protocol data unit (PDU). Such a packetcan, for example, include payload data as well as metadata in the formof control data. Control data can, for example, provide data to assistthe network node with reliably delivering the payload data. For example,control data can include network addresses for source node 128 anddestination node 130, error detection codes, sequencing information,packet size of the packet, a time-to-live (TTL) value, etc. In contrast,payload data can include data carried on behalf of an application foruse by nodes (e.g., source node 128 and destination node 130).

As provided above, in an SDN (such as for example heterogeneous network100), control decisions for routing traffic through the network can bedecoupled from the network's physical infrastructure. For example, SDNcontroller 102 can be used to instruct network nodes to flow trafficalong a selected routing path defined by the nodes. It is appreciatedthat the routing path can be determined by SDN controller 102 based onone or more static parameters, such as link speeds and number hopsbetween the nodes and can further (or alternatively) be based on one ormore dynamic parameters, such as Quality of Service (QoS), networklatency, network throughput, network power consumption, etc.

In some implementations, these nodes can, for example, be in the form ofnetwork switches or other intermediary network devices. The use of suchsoftware-defined networking can provide other functionality. Forexample, one or more applications can be installed on or interface withSDN controller 102 to meet customer use cases, such as to achieve adesired throughput (or another QoS) over heterogeneous network 100,enforce security provisions for heterogeneous network 100, or provideanother suitable service or functionality.

The functionality of SDN controller 102 can, for example, be implementedin part via a software program on a standalone machine, such as astandalone server. In some implementations, SDN controller 102 can beimplemented on multi-purpose machines, such as a suitable desktopcomputer, laptop, tablet, or the like. In some implementations, SDNcontroller 102 can be implemented on a suitable non-host network node,such as certain types of network switches. It is appreciated that thefunctionality of SDN controller 102 may be split among multiplecontrollers or other devices. For example, heterogeneous network 100 isdescribed and illustrated as including only one SDN controller 102.However, it is appreciated that the disclosure herein can be implementedin SDNs with multiple controllers. For example, in some SDNs, networkdevices are in communication with multiple controllers such that controlof the network can be smoothly handed over from a first controller to asecond controller if a first controller fails or is otherwise out ofoperation. As another example, multiple controllers can work together toconcurrently control certain SDNs. In such SDNs, a first controller can,for example, control certain network devices while a second controllercan control other network devices. In view of the above, reference inthis application to a single SDN controller 102 that controls theoperation of heterogeneous network 100 is intended to include suchmultiple controller configurations (and other suitable multiplecontroller configurations).

Source node 128 and destination nodes 130 and 132 can, for example, bein the form of network hosts or other types of network nodes. Forexample, one or all of source node 128 and destination nodes 130 and 132can be in the form of suitable servers, desktop computers, laptops,printers, etc. As but one example, source node 128 can be in the form ofa desktop computer including a monitor for presenting information to anoperator and a keyboard and mouse for receiving input from an operator,and destination nodes 130 and 132 can be in the form of respectivestandalone storage server appliances. It is further appreciated thatsource node 128 and destination nodes 130 and 132 can be endpoint nodeson heterogeneous network 100, intermediate nodes between endpoint nodes,or positioned at other logical or physical locations withinheterogeneous network 100.

The various intermediary nodes within heterogeneous network 100 can, forexample, be in the form of switches or other multi-port network bridgesthat process and forward data at the data link layer. In someimplementations, one or more of the nodes can be in the form ofmultilayer switches that operate at multiple layers of the Open SystemsConnection (OSI) model (e.g., the data link and network layers).Although the term “switch” is used throughout this description, it isappreciated that this term can refer broadly to other suitable networkdata forwarding devices. For example, the term “switch” can includeother network datapath elements in the form of suitable routers,gateways and other devices that provide switch-like functionality forheterogeneous network 100. As another example, a general purposecomputer can include suitable hardware and machine-readable instructionsthat allow the computer to function as a network switch.

In some implementations, an SDN-capable switch (e.g., SDN switches 108,110, 112, 114, and/or hybrid border switches 116, 118, and 120) inheterogeneous network 100 can rely on flow rules stored on the switch(or otherwise accessible by the switch) for forwarding or otherwisehandling traffic. Flow rules can, for example, contain information suchas: (1) match fields to match against packets (e.g., an ingress port andspecific packet header fields), (2) a priority value for the flow ruleto allow prioritization over other flow entries, (3) counters that areupdated when packets are matched, (4) instructions to modify the actionset or pipeline processing, (5) timeouts indicating a maximum amount oftime or idle time before a flow is expired by the switch, and (6) acookie value which can be used by the SDN controller to filter flowstatistics, flow modification, and flow deletion.

The various nodes within heterogeneous network 100 are connected via oneor more data channels, which can, for example be in the form of datacables or wireless data channels. Although a single link (i.e., a singleline in FIG. 1) between each network node is illustrated, it isappreciated that each single link may include multiple wires or otherwired or wireless data channels. Moreover, FIG. 1 further depicts SDNcontroller 102 as being connected to each network nodes via brokenlines, which is intended to illustrate control channels between SDNcontroller 102 and respective nodes. However, it is appreciated that SDNcontroller 102 may be directly connected to only one or a few networknodes, while being indirectly connected to other nodes of heterogeneousnetwork 100. As but one example, SDN controller 102 can be directlyconnected to node 108 via an Ethernet cable, while being indirectlyconnected to node 112 (e.g., by relying on node 108 as an intermediaryfor communication with node 112).

Within the context of an SDN, controlled network nodes can be used assensors in the network as they have information about dynamic networkparameters. When polled via standard SDN interfaces the devices canreport this information to SDN controller 102. Heterogeneous network 100can, for example, be implemented through the use of SDN controller 102that interfaces with various SDN-compatible devices via a suitableApplication Program Interface (“API”), or another suitable protocol(e.g., OpenFlow). In some implementations, SDN controller 102 mayinterface with controlled network devices via an interface channel thatconnects each controlled device to SDN controller 102 to allow SDNcontroller 102 to configure and manage each device, receive events fromeach device, and send packets using each device.

In the example heterogeneous network 100 depicted in FIG. 1, the variousnetwork nodes are in the form of intermediary nodes (e.g., controllednetwork switch 108) and host devices (e.g., source node 128 anddestination nodes 130 and 132). It is appreciated however, that theimplementations described herein can be used or adapted for networksincluding more or fewer devices, different types of devices, anddifferent network arrangements.

FIG. 2 illustrates a flowchart for a method 134 according to an exampleof the present disclosure. For illustration, the description of method134 and its component steps make reference to example heterogeneousnetwork 100 and elements thereof, such as for example SDN controller102, however, it is appreciated that method 134 or aspects thereof canbe used or otherwise applicable for any suitable network or networkelement described herein or otherwise. For example, method 134 can beapplied to computer networks with different network topologies thanthose illustrated in FIG. 1.

In some implementations, method 134 can be implemented in the form ofexecutable instructions stored on a memory resource (e.g., the memoryresource of FIG. 6), executable machine readable instructions stored ona storage medium (e.g., the medium of FIG. 7), in the form of electroniccircuitry (e.g., on an Application-Specific Integrated Circuit (ASIC)),and/or another suitable form. Although the description of method 134herein primarily refers to steps performed on SDN controller 102 forpurposes of illustration, it is appreciated that in someimplementations, method 134 can be executed on another computing devicewithin heterogeneous network 100 or in data communication with SDNcontroller 102.

Method 134 includes determining (at block 136), with SDN controller 102,a network topology for SDN portion 111 of heterogeneous network 100. SDNportion 111 can, for example, be formed by hybrid and SDN devices.Heterogeneous network 100 can further include a non-SDN portion thatborders SDN portion 111 and can, for example, be formed by non-SDNdevices. In the heterogeneous network 100 of FIG. 1, switches 116, 118,and 120 serve as border switches between SDN portion 111 ofheterogeneous network 100 and the non-SDN portion of heterogeneousnetwork 100. In the heterogeneous network 100 of FIG. 1, SDN portion 111includes switches 116, 118, 120, 108, 110, 112, and 114, as well asdestination node 132 and SDN controller 102. The non-SDN portion ofheterogeneous network 100 includes switches 122, 124, and 126 as well assource node 128 and destination node 130. Although only a single SDNportion is depicted in FIG. 1, in some implementations, heterogeneousnetwork 100 can include multiple SDN portions.

In some implementations, the switches 116, 118, 120, 108, 110, 112, and114 are within the control domain of SDN controller 102. As used herein,the term “controlled” and similar terminology in the context ofSDN-compatible network nodes, such as “controlled switches,” is intendedto include devices within the control domain of SDN controller 102 orotherwise similarly controllable by SDN controller 102. Such acontrolled node can, for example, communicate with SDN controller 102and SDN controller 102 is able to manage the node in accordance with anSDN protocol, such as the OpenFlow protocol. For example, anOpenFlow-compatible switch controlled by SDN controller 102 can permitSDN controller 102 to add, update, and delete flow entries in flowtables of the switch using suitable SDN commands.

In some implementations, the network topology is determined based onBi-directional Forwarding Detection (BFD) connectivity informationreceived from SDN devices in heterogeneous network 100. In some suchimplementations, each device in SDN portion 111 of heterogeneous network100 runs BFD to each of its connected devices and passes theconnectivity information to SDN controller 102. SDN controller 102 canthen identify the network topology using this information.

Method 134 includes sending (at block 138) tunneling instructions to afirst hybrid border switch (e.g., switch 116) to create a tunnel betweenthe first hybrid border switch and a second hybrid border switch inorder to allow Open Shortest Path First (OSPF) routing between twonon-SDN portions separated by an SDN portion within the heterogeneousnetwork. The two non-SDN portions can, for example, be separated by anSDN portion because SDN portion 111 communicatively bridges the twonon-SDN portions. In some implementations, the SDN controller sendstunneling instructions to every hybrid border switch in SDN portion 111to create tunnels between each of the hybrid border switches (e.g.,between switch 116 and switch 118, between switch 116 and switch 120,and between switch 118 and switch 120) in order to allow OSPF routingbetween any two hybrid border switches.

In some implementations, SDN controller 102 is to install tunnelsbetween border switches (e.g., 116, 118, and 120) so that OSPFconnectivity is maintained between non-SDN devices partitioned by SDNdevices. That is, routing between two such non-SDN portions ofheterogeneous network 100 can, for example, be achieved through the useof tunnels between border devices. Routing within one area of non-SDNdevices can, for example, be based on normal OSPF functionality. Routingwithin SDN-only portions of heterogeneous network 100 can, for example,be achieved by SDN controller 102 installing respective flow entries toswitches within SDN portion 111s. Likewise, routing from SDN devices tonon-SDN devices can, for example, pass through one of the borderswitches based on the OSPF routes learned by that border switch andaided by SDN controller 102 to reach the border switch. Routing fromnon-SDN devices to SDN devices can, for example, be achieved by thestatic routes redistributed by the border switch. Once data (e.g., inthe form of a packet) reaches the border switch, further forwarding canbe handled by SDN controller 102 through flow entries. Border switchesfor use with the present disclosure can, for example, have someinterfaces on SDN portion 111 of heterogeneous network 100 and someinterfaces on the non-SDN portion of heterogeneous network 100 but canbe otherwise distinct from the “Area Border Router” and “AutonomousSystem Border Router” defined by OSPF standards.

Although the flowchart of FIG. 2 shows a specific order of performance,it is appreciated that this order may be rearranged into anothersuitable order, may be executed concurrently or with partialconcurrence, or a combination thereof. Likewise, suitable additionaland/or comparable steps may be added to method 134 or other methodsdescribed herein in order to achieve the same or comparablefunctionality. In some implementations, one or more steps are omitted.For example, in some implementations, block 138 of sending tunnelinginstructions can be omitted from method 134 and/or replaced with anotherfunction. It is appreciated that blocks corresponding to additional oralternative functionality of other implementations described herein canbe incorporated in method 134. For example, blocks corresponding to thefunctionality of various aspects of SDN controller 102 otherwisedescribed herein can be incorporated in method 134 even if suchfunctionality is not explicitly characterized herein as a block inmethod 134.

FIG. 3 illustrates another example of method 134 in accordance with thepresent disclosure. For illustration, FIG. 3 reproduces various blocksfrom method 134 of FIG. 2, however it is appreciated that method 134 ofFIG. 3 can include additional, alternative, or fewer steps,functionality, etc., than method 134 of FIG. 2 and is not intended to belimited by the diagram of FIG. 2 (or vice versa) or the relateddisclosure thereof. It is further appreciated that method 134 of FIG. 2can incorporate one or more aspects of method 134 of FIG. 3 and viceversa. For example, in some implementations, method 134 of FIG. 2 caninclude the additional step described below with respect to method 134of FIG. 3.

Method 134 includes sending (at block 140) static route installationinstructions to the first hybrid border switch (e.g., switch 116) toallow OSPF routing from the non-SDN portion to SDN portion 111. In someimplementations, the static route installation instructions are to allowdevices in the non-SDN portion to reach a subnet within SDN portion 111.Routes learned by border switches from OSPF will be passed to SDNcontroller 102. SDN controller 102 can, for example, use thisinformation to derive flow entries for handling packet forwarding in theSDN-only portion of heterogeneous network 100.

For example, in some implementations, block 140 includes installingstatic routes to hybrid border switches of SDN portion 111 ofheterogeneous network 100. In some implementations, each devicebordering SDN portion 111 of the network is a hybrid device that runsprotocols to support both SDN portion 111 and the non-SDN portion ofheterogeneous network 100. In some implementations, static routes forreaching each subnet of SDN portion 111 are installed on border switchesbetween a border of SDN portion 111 and the non-SDN portion. Theseroutes can, for example, be redistributed by the border switch to thenon-SDN portion of heterogeneous network 100. Non-SDN devices can, forexample, run OSPF and can, for example, compute the best paths to theother devices. Devices on the border of SDN portion 111 of theheterogeneous network 100 can, for example, run OSPF on an interface tothe non-SDN portion of heterogeneous network 100 and can use the staticroute installed by SDN controller 102 to route into SDN portion 111 ofheterogeneous network 100.

FIG. 4 illustrates another example of method 134 in accordance with thepresent disclosure. For illustration, FIG. 4 reproduces various blocksfrom method 134 of FIG. 2, however it is appreciated that method 134 ofFIG. 4 can include additional, alternative, or fewer steps,functionality, etc., than method 134 of FIG. 2 and is not intended to belimited by the diagram of FIG. 2 (or vice versa) or the relateddisclosure thereof. It is further appreciated that method 134 of FIG. 2can incorporate one or more aspects of method 134 of FIG. 4 and viceversa. For example, in some implementations, method 134 of FIG. 2 caninclude the additional step described below with respect to method 134of FIG. 4. Method 134 of FIG. 4 includes receiving (at block 142), froma hybrid border switch (e.g., switch 116), route information determinedby the hybrid border switch from OSPF routing.

FIG. 5 illustrates another example of method 134 in accordance with thepresent disclosure. For illustration, FIG. 5 reproduces various blocksfrom method 134 of FIG. 2, however it is appreciated that method 134 ofFIG. 5 can include additional, alternative, or fewer steps,functionality, etc., than method 134 of FIG. 2 and is not intended to belimited by the diagram of FIG. 2 (or vice versa) or the relateddisclosure thereof. It is further appreciated that method 134 of FIG. 2can incorporate one or more aspects of method 134 of FIG. 5 and viceversa. For example, in some implementations, method 134 of FIG. 2 caninclude the additional step described below with respect to method 134of FIG. 5. Method 134 of FIG. 5 includes determining (at block 144),with SDN controller 102, a flow entry for the hybrid border switch tohandle packet routing from the non-SDN portion to SDN portion 111.Method 134 of FIG. 5 further includes installing (at block 146) thedetermined flow entry on the hybrid border switch.

FIG. 6 is a diagram of one implementation of SDN controller 102. Asdescribed in further detail below, SDN controller 102 includes aprocessing resource 148 and a memory resource 150 that storesmachine-readable instructions 152, 154, and 156. For illustration, thedescription of SDN controller 102 of FIG. 6 makes reference to variousaspects of method 134 of FIGS. 2-5. Indeed, for consistency, the samereference number for the SDN controller of FIG. 1 is used for the SDNcontroller of FIG. 6. However it is appreciated that the SDN controllerof FIG. 6 can include additional, alternative, or fewer aspects,functionality, etc., than the implementation described with respect tomethod 134 as well as the SDN controller of FIG. 1 and is not intendedto be limited by the related disclosure thereof.

Instructions 152 stored on memory resource 150 are, when executed byprocessing resource 148, to cause processing resource 148 to receive BFDconnectivity information from an SDN device in heterogeneous network100. Instructions 152 can incorporate one or more aspects of blocks ofmethod 134 or another suitable aspect of other implementations describedherein (and vice versa).

Instructions 154 stored on memory resource 150 are, when executed byprocessing resource 148, to cause processing resource 148 to determine anetwork topology for an SDN portion of heterogeneous network 100. Asprovided herein, SDN portion 111 can, for example, separate a firstnon-SDN portion of heterogeneous network 100 and a second non-SDNportion of heterogeneous network 100. Instructions 154 can incorporateone or more aspects of blocks of method 134 or another suitable aspectof other implementations described herein (and vice versa).

Instructions 156 stored on memory resource 150 are, when executed byprocessing resource 148, to cause processing resource 148 to sendtunneling instructions to a first hybrid border switch in SDN portion111 that borders the first non-SDN portion. As provided above, the firsthybrid border switch can, for example, include a first interface thatsupports non-SDN protocols and a second interface that supports SDNprotocols. The tunneling instructions can, for example, create a tunnelbetween the first hybrid border switch and a second hybrid border switchin order to allow OSPF routing between the first non-SDN portion and thesecond non-SDN portion. Instructions 156 can incorporate one or moreaspects of blocks of method 134 or another suitable aspect of otherimplementations described herein (and vice versa).

Processing resource 148 of SDN controller 102 can, for example, be inthe form of a central processing unit (CPU), a semiconductor-basedmicroprocessor, a digital signal processor (DSP) such as a digital imageprocessing unit, other hardware devices or processing elements suitableto retrieve and execute instructions stored in memory resource 150, orsuitable combinations thereof. Processing resource 148 can, for example,include single or multiple cores on a chip, multiple cores acrossmultiple chips, multiple cores across multiple devices, or suitablecombinations thereof. Processing resource 148 can be functional tofetch, decode, and execute instructions as described herein. As analternative or in addition to retrieving and executing instructions,processing resource 148 can, for example, include at least oneintegrated circuit (IC), other control logic, other electronic circuits,or suitable combination thereof that include a number of electroniccomponents for performing the functionality of instructions stored onmemory resource 150. The term “logic” can, in some implementations, bean alternative or additional processing resource to perform a particularaction and/or function, etc., described herein, which includes hardware,e.g., various forms of transistor logic, application specific integratedcircuits (ASICs), etc., as opposed to machine executable instructions,e.g., software firmware, etc., stored in memory and executable by aprocessor. Processing resource 148 can, for example, be implementedacross multiple processing units and instructions may be implemented bydifferent processing units in different areas of SDN controller 102.

Memory resource 150 of SDN controller 102 can, for example, be in theform of a non-transitory machine-readable storage medium, such as asuitable electronic, magnetic, optical, or other physical storageapparatus to contain or store information such as machine-readableinstructions 152, 154, and 156. Such instructions can be operative toperform one or more functions described herein, such as those describedherein with respect to method 134 or other methods described herein.Memory resource 150 can, for example, be housed within the same housingas processing resource 148 for SDN controller 102, such as within acomputing tower case for SDN controller 102. In some implementations,memory resource 150 and processing resource 148 are housed in differenthousings. As used herein, the term “machine-readable storage medium”can, for example, include Random Access Memory (RAM), flash memory, astorage drive (e.g., a hard disk), any type of storage disc (e.g., aCompact Disc Read Only Memory (CD-ROM), any other type of compact disc,a DVD, etc.), and the like, or a combination thereof. In someimplementations, memory resource 150 can correspond to a memoryincluding a main memory, such as a Random Access Memory (RAM), wheresoftware may reside during runtime, and a secondary memory. Thesecondary memory can, for example, include a nonvolatile memory where acopy of machine-readable instructions are stored. It is appreciated thatboth machine-readable instructions as well as related data can be storedon memory mediums and that multiple mediums can be treated as a singlemedium for purposes of description.

Processing resource 148 and memory resource 150 can, for example, be incommunication via a communication link 158. Each communication link 158can be local or remote to a machine (e.g., a computing device)associated with processing resource 148. Examples of a localcommunication link 158 can include an electronic bus internal to amachine (e.g., a computing device) where memory resource 150 is one ofvolatile, non-volatile, fixed, and/or removable storage medium incommunication with processing resource 148 via the electronic bus.

In some implementations, one or more aspects of SDN controller 102 canbe in the form of functional modules that can, for example, be operativeto execute one or more processes of instructions 152, 154, or 156 orother functions described herein relating to other implementations ofthe disclosure. As used herein, the term “module” refers to acombination of hardware (e.g., a processor such as an integrated circuitor other circuitry) and software (e.g., machine- or processor-executableinstructions, commands, or code such as firmware, programming, or objectcode). A combination of hardware and software can include hardware only(i.e., a hardware element with no software elements), software hosted athardware (e.g., software that is stored at a memory and executed orinterpreted at a processor), or hardware and software hosted athardware. It is further appreciated that the term “module” isadditionally intended to refer to one or more modules or a combinationof modules. Each module of SDN controller 102 can, for example, includeone or more machine-readable storage mediums and one or more computerprocessors.

In view of the above, it is appreciated that the various instructions ofSDN controller 102 described above can correspond to separate and/orcombined functional modules. For example, instructions 152 cancorrespond to an “connectivity information receiving module” to receiveBFD connectivity information from an SDN device in a heterogeneousnetwork; instructions 154 can correspond to a “topology determinationmodule” (see, e.g., module 104 of FIG. 1) to determine a networktopology for an SDN portion of a heterogeneous network; and instructions156 can correspond to a “tunneling instructions module” (see, e.g.,module 106 of FIG. 1) to send tunneling instructions to a first hybridborder switch (e.g., switch 116) in SDN portion 111 that borders thefirst non-SDN portion. It is further appreciated that a given module canbe used for multiple functions. As but one example, in someimplementations, a single module can be used to both receiveconnectivity information (corresponding to aspects of instructions 152)as well as to determine the network topology (corresponding to aspectsof instructions 154).

One or more nodes within heterogeneous network 100 (e.g., SDN controller102) can further include a suitable communication module to allownetworked communication between SDN controller 102 and other elements ofheterogeneous network 100. Such a communication module can, for example,include a network interface controller having an Ethernet port and/or aFibre Channel port. In some implementations, such a communication modulecan include wired or wireless communication interface, and can, in someimplementations, provide for virtual network ports. In someimplementations, such a communication module includes hardware in theform of a hard drive, related firmware, and other software for allowingthe hard drive to operatively communicate with other hardware of SDNcontroller 102 or other network equipment. The communication module can,for example, include machine-readable instructions for use withcommunication the communication module, such as firmware forimplementing physical or virtual network ports.

FIG. 7 illustrates a machine-readable storage medium 160 includingvarious instructions that can be executed by a computer processor orother processing resource. In some implementations, medium 160 can behoused within a physical SDN controller, such as certain implementationsof SDN controller 102, or on another computing device withinheterogeneous network 100 or in local or remote wired or wireless datacommunication with heterogeneous network 100.

For illustration, the description of machine-readable storage medium 160provided herein makes reference to various aspects of SDN controller 102(e.g., processing resource 148) and other implementations of thedisclosure (e.g., method 134). Although one or more aspects of SDNcontroller 102 (as well as certain instructions, such as instructions152, 154, and 156) can be applied or otherwise incorporated with medium160, it is appreciated that in some implementations, medium 160 may bestored or housed separately from such a system. For example, in someimplementations, medium 160 can be in the form of Random Access Memory(RAM), flash memory, a storage drive (e.g., a hard disk), any type ofstorage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any othertype of compact disc, a DVD, etc.), and the like, or a combinationthereof. In some implementations, medium 160 is a physical medium housedwithin a physical chassis of an SDN controller, such as certainimplementations of SDN controller 102.

Medium 160 includes machine-readable instructions 162 stored thereon tocause processing resource 148 to determine a network topology for an SDNportion of heterogeneous network 100. Instructions 162 can, for example,incorporate one or more aspects of block 136 of method 134 orinstructions 154 of SDN controller 102 or another suitable aspect ofother implementations described herein (and vice versa).

Medium 160 includes machine-readable instructions 164 stored thereon tocause processing resource 148 to send static route installationinstructions to a hybrid border switch to allow OSPF routing from anon-SDN portion of heterogeneous network 100 to a device within SDNportion 111 of heterogeneous network 100. Instructions 164 can, forexample, incorporate one or more aspects of block 138 of method 134 oranother suitable aspect of other implementations described herein (andvice versa).

While certain implementations have been shown and described above,various changes in form and details may be made. For example, somefeatures that have been described in relation to one implementationand/or process can be related to other implementations. In other words,processes, features, components, and/or properties described in relationto one implementation can be useful in other implementations.Furthermore, it should be appreciated that the systems and methodsdescribed herein can include various combinations and/orsub-combinations of the components and/or features of the differentimplementations described. Thus, features described with reference toone or more implementations can be combined with other implementationsdescribed herein.

As used herein, “logic” is an alternative or additional processingresource to perform a particular action and/or function, etc., describedherein, which includes hardware, e.g., various forms of transistorlogic, application specific integrated circuits (ASICs), etc., asopposed to machine executable instructions, e.g., software firmware,etc., stored in memory and executable by a processor. Further, as usedherein, “a” or “a number of” something can refer to one or more suchthings. For example, “a number of widgets” can refer to one or morewidgets. Also, as used herein, “a plurality of” something can refer tomore than one of such things.

What is claimed is:
 1. A method comprising: determining, with aSoftware-Defined Networking (SDN) controller, a network topology for anSDN portion of a heterogeneous network, wherein SDN portion 111 isformed by hybrid and SDN devices, and wherein the heterogeneous networkincludes a non-SDN portion that borders SDN portion 111 and is formed bynon-SDN devices; and sending tunneling instructions to a first hybridborder switch to create a tunnel between the first hybrid border switchand a second hybrid border switch in order to allow Open Shortest PathFirst (OSPF) routing between two non-SDN portions separated by an SDNportion within the heterogeneous network.
 2. The method of claim 1,further comprising: sending static route installation instructions tothe first hybrid border switch to allow OSPF routing from the non-SDNportion to SDN portion
 111. 3. The method of claim 2, wherein the staticroute installation instructions are to allow devices in the non-SDNportion to reach a subnet within SDN portion
 111. 4. The method of claim1, wherein the network topology is determined based on Bi-directionalForwarding Detection (BFD) connectivity information received from SDNdevices in the heterogeneous network.
 5. The method of claim 1, whereinthe first hybrid border switch supports protocols for both SDN andnon-SDN devices.
 6. The method of claim 1, wherein the hybrid and SDNdevices are within the control domain of the SDN controller.
 7. Themethod of claim 1, further comprising: receiving, from a hybrid borderswitch, route information determined by the hybrid border switch fromOSPF routing.
 8. The method of claim 1, wherein the two non-SDN portionsare separated by an SDN portion because SDN portion 111 communicativelybridges the two non-SDN portions.
 9. The method of claim 1, furthercomprising: determining, with the SDN controller, a flow entry for thehybrid border switch to handle packet routing from the non-SDN portionto SDN portion 111; and installing the determined flow entry on thehybrid border switch.
 10. The method of claim 1, wherein the SDNcontroller sends tunneling instructions to every hybrid border switch inSDN portion 111 to create tunnels between each of the hybrid borderswitches in order to allow OSPF routing between any two hybrid borderswitches.
 11. The method of claim 1, wherein the heterogeneous networkis a virtualized heterogeneous network.
 12. A non-transitory machinereadable storage medium having stored thereon machine readableinstructions to cause a computer processor to: determine a networktopology for a Software-Defined Networking (SDN) portion of aheterogeneous network; and send static route installation instructionsto a hybrid border switch to allow OSPF routing from a non-SDN portionof the heterogeneous network to a device within SDN portion 111 of theheterogeneous network.
 13. The medium of claim 12, wherein the medium isa physical medium housed within a physical SDN controller chassis.
 14. ASoftware-Defined Networking (SDN) controller comprising: a processingresource; and a memory resource storing machine readable instructions tocause the processing resource to: receive Bi-directional ForwardingDetection (BFD) connectivity information from an SDN device in aheterogeneous network, wherein the heterogeneous network furtherincludes a non-SDN portion that borders SDN portion 111 and is formed bynon-SDN devices; determine a network topology for an SDN portion of aheterogeneous network, SDN portion 111 separating a first non-SDNportion of the heterogeneous network and a second non-SDN portion of theheterogeneous network; and send tunneling instructions to a first hybridborder switch in SDN portion 111 that borders the first non-SDN portion,the first hybrid border switch including a first interface that supportsnon-SDN protocols and a second interface that supports SDN protocols,wherein the tunneling instructions are to create a tunnel between thefirst hybrid border switch and a second hybrid border switch in order toallow Open Shortest Path First (OSPF) routing between the first non-SDNportion and the second non-SDN portion.
 15. The SDN controller of claim14, wherein the memory resource further stores machine readableinstructions to cause the processing resource to: send static routeinstallation instructions to the first hybrid border switch, wherein thestatic routes are determined by the SDN controller to handle forwardingof packets between the non-SDN portion to SDN portion 111.